home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-3451 / data / 50hz.dat < prev    next >
Text File  |  1987-04-21  |  7KB  |  136 lines
  1.                      Hertz - The Mystery Explained.
  2.                       Written by Wheee the fibble.
  3.  
  4.     Ok, anyone who has ever looked at an assembly demo like The 
  5. European Demos or Mindbomb, or even Enchanted Lands I suppose, 
  6. will have been rather immpressed by the speed and smoothness of 
  7. the graphics.  Most STOS coders I've spoken to have put this down 
  8. to the rather mysterious reason that it was written in ASSEMBLY.  
  9. Nothing to do with good programming or anything, just the mere 
  10. fact that it was written in ASSEMBLY made it fast and smooth.  The 
  11. reason the same people give for their demo screens graphics flicking 
  12. and jerking around the screen is just that it was written in STOS, 
  13. and of course, therefore couldn't ever hope to go that fast.  Now, 
  14. most people reading this will, I hope, be thinking "Phew, how 
  15. silly - I know that isn't the reason."  But, how many of us can 
  16. claim never to have blamed STOS for our screens/programmes looking 
  17. crap?  Not many I suspect.  It must be said of course that STOS is 
  18. responsable for many problems and errors, but there we go, can't 
  19. have everything...
  20.     Well, if you are still wondering why it is that assembly 
  21. screens look so smooth I'll just explain...
  22.     The TV/Monitor you're looking at has it's picture updated 50 
  23. times a second (or 60 if it's a colour monitor, or 70 if it's 
  24. mono).  The screen is drawn by a little "gun" which fire electrons 
  25. at the screen, making it glow the colour of the picture at that 
  26. point on the screen. The gun moves from the top left of the 
  27. picture to the bottom right, line by line.  The time it takes for 
  28. the gun to draw 1 line from left to right is called a "Horizontal 
  29. blank", and the time for the whole screen to be drawn is a 
  30. "Verticle blank".  Incedently, there is also the time taken for 
  31. the gun to jump from the bottom right back to the top left again, 
  32. but I'll ignore that for the moment...
  33.     Now, in order to get your screens looking perfectly smooth 
  34. (like (almost) all the screens in the "Ever-So-Wonderful" Better 
  35. Than Life Demo) you have to get all of your graphics, music and 
  36. sprite operations completed before the gun reaches the bottom 
  37. right of the screen, ie, you must get your program to do 
  38. everything in under 1/50th of a second!  Almost all assembly 
  39. screens do this, that is why the graphics move so smoothly - they 
  40. are exactly in sync with the vertical blank so that every time the 
  41. gun goes back to the top left of the screen, the graphics have 
  42. been moved to their next positions and so appear to move really 
  43. smoothly...  STOS screens on the other hand usually are not in 
  44. sync with the vertical blank, thus they seem to flicker or wobble 
  45. around the screen.  
  46.     The major cause of this is trying to get STOS to do too much 
  47. of the work.  There are many STOS demo screens where people have 
  48. tried to get as much stuff as there is on assembly demos and end 
  49. up with a jerky mess.  There are many ways to stop this sort of 
  50. thing happening.  One is not to use STOS sprites - they're crap.
  51. Try this little test program for instance which will show you the 
  52. difference between STOS sprites and screen copy sprites...
  53.  
  54. 10 timer=0:forT=1 to 100:sprite 1,15,0,1:nextT:T=timer:?T
  55. 20 timer=0:forT=1 to 100:screencopy physic,0,0,16,16toback,0,0:
  56. nextT:T=timer:?T
  57.  
  58.     It assumes that the sprite you're using is 16x16, but it should 
  59. still show a rather major difference between the two methods.  
  60. There are many other ways of saving time in your programs, too 
  61. many to go into here, but safe to say that there are many, many 
  62. ways to get round STOS's problems...
  63.     Now, inside your main loop  there should be a line something 
  64. like this:-
  65.  
  66. 100 screen swap : waitvbl
  67.  
  68.     This will swap the addresses of the logical and physical 
  69. screens so that the whole screen is drawn at once, and the wait 
  70. vbl will wait for the next vertical blank to occur.  If you want 
  71. your screen to go at 50 hertz (in sync with the vbl) you will have 
  72. to change the line to read:-
  73.  
  74. 100 screen swap : doke $ffff8240,$777 : doke $ffff8240,$000 : wait vbl
  75.  
  76.     This, when run, will put a little raster line on the screen 
  77. which will show you where the electron gun has reached after doing 
  78. all of your graphics and music.  The amount of space left 
  79. underneath it is how much processor time you have left to do more 
  80. things in your screen!  Be careful though, the line will come out 
  81. of the top of the screen again if you have used up all of the 
  82. proccessor time (or more), so be careful that the routine you 
  83. think is really fast, is in fact really slow...  It's best to 
  84. build up your screen so that you can see how much time you have 
  85. left, and how much each new part is taking up.  Ideally, 
  86. everything should be complete before the raster hits the bottom of 
  87. the screen, if this is so then your screen can be said to be 
  88. running at 50 hertz and, should, look very smooth!  If the raster 
  89. has gone out of the bottom of the screen and come in the top again 
  90. then your screen is said to be running at 25 hertz.  No releasable 
  91. demoscreen should ever be at less the 25 hertz, and even the 25 
  92. hertz ones are very unusual.  Run this little program to 
  93. demonstrate what I mean (use + and - to change the number of 
  94. dots), it should be on the disk called "hztest.bas":-
  95.  
  96. 10 key off : curs off : auto back off : hide on : mode 0
  97. 20 MX=1 : X=1
  98. 30 logic=back
  99. 40 repeat 
  100. 45 for T=1 to MX : plot OLDX,T*4,0 : next T
  101. 50 for T=1 to MX : plot X,T*4,1 : next T : OLDX=X : X=X mod 319+1
  102. 60 screen swap : doke $FFFF8240,$7 : doke $FF8240,$0 : wait vbl 
  103. 70 G$=inkey$
  104. 80 until (G$="+") or (G$="-") or (G$=" ")
  105. 90 if G$=" " then default : end 
  106. 100 if G$="-" and MX>1 then dec MX
  107. 110 if G$="+" and MX<49 then inc MX
  108. 120 clear key : goto 40
  109.  
  110.     If you watch the raster, the points should look nice and 
  111. smooth until it goes out of the bottom and comes in the top 
  112. again.  That's the difference between 50 and 25 hertz!  So, if you 
  113. want your screens to look as smooth as those in assembly demos or 
  114. those in the Better Than Life demo, just make sure that your 
  115. screen does everything before the line goes out of the bottom of 
  116. the screen...
  117.     Incedently, if you have a colour monitor and your running in 
  118. 60 hertz, you do realise that this means you have to goet all of 
  119. your grphics/music operations completed within 1/60th of a 
  120. second???  That's why you see many programs talking about 
  121. "Forcing" 50 hertz.  In order to do this in STOS you'll have to 
  122. muck around with the value in location $ffff820a, try this little 
  123. routine to find out which values to put in:-
  124.  
  125. frequency:f1=peek($ffff820a):frequency:f2=peek($ffff820a):?f1,f2
  126.  
  127.     Well, I hope you understood all that, and I hope to see some 
  128. more smooth screens in future...   If you want to get in touch, 
  129. call me at (0389) 64820 and ask for Billy...
  130.  
  131.                     Bye then...
  132.  
  133. note from editor: 60 hertz isn't as painful as ten shap lashes 
  134. with ten foot steel rod.
  135.  
  136.